Computers include general purpose central processing units (CPUs) that are designed to execute a specific set of system instructions. A group of processors that have similar architecture or design specifications may be considered to be members of the same processor family. Examples of current processor families include the Motorola 680X0 processor family, manufactured by Motorola, Inc. of Phoenix, Ariz.; the Intel 80X86 processor family, manufactured by Intel Corporation of Sunnyvale, Calif.; and the PowerPC processor family, which is manufactured by Motorola, Inc. and used in computers manufactured by Apple Computer, Inc. of Cupertino, Calif. Although a group of processors may be in the same family because of their similar architecture and design considerations, processors may vary widely within a family according to their clock speed and other performance parameters.
Each family of microprocessors executes instructions that are unique to the processor family. The collective set of instructions that a processor or family of processors can execute is known as the processor's instruction set. As an example, the instruction set used by the Intel 80X86 processor family is incompatible with the instruction set used by the PowerPC processor family. The Intel 80X86 instruction set is based on the Complex Instruction Set Computer (CISC) format. The Motorola PowerPC instruction set is based on the Reduced Instruction Set Computer (RISC) format. CISC processors use a large number of instructions, some of which can perform rather complicated functions, but which require generally many clock cycles to execute. RISC processors use a smaller number of available instructions to perform a simpler set of functions that are executed at a much higher rate.
The uniqueness of the processor family among computer systems also typically results in incompatibility among the other elements of hardware architecture of the computer systems. A computer system manufactured with a processor from the Intel 80X86 processor family will have a hardware architecture that is different from the hardware architecture of a computer system manufactured with a processor from the PowerPC processor family. Because of the uniqueness of the processor instruction set and a computer system's hardware architecture, application software programs are typically written to run on a particular computer system running a particular operating system.
Processor Virtualization
Computer manufacturers want to maximize their market share by having more rather than fewer applications run on the microprocessor family associated with the computer manufacturers' product line. To expand the number of operating systems and application programs that can run on a computer system, a field of technology has developed in which a given computer having one type of CPU, called a host, will include an emulator program that allows the host computer to emulate the instructions of an unrelated type of CPU, called a guest. Thus, the host computer will execute an application that will cause one or more host instructions to be called in response to a given guest instruction. Thus the host computer can both run software design for its own hardware architecture and software written for computers having an unrelated hardware architecture. As a more specific example, a computer system manufactured by Apple Computer, for example, may run operating systems and program written for PC-based computer systems. It may also be possible to use an emulator program to operate concurrently on a single CPU multiple incompatible operating systems. In this arrangement, although each operating system is incompatible with the other, an emulator program can host one of the two operating systems, allowing the otherwise incompatible operating systems to run concurrently on the same computer system.
When a guest computer system is emulated on a host computer system, the guest computer system is said to be a “virtual machine” as the guest computer system only exists in the host computer system as a pure software representation of the operation of one specific hardware architecture. The terms emulator, virtual machine, and processor emulation are sometimes used interchangeably to denote the ability to mimic or emulate the hardware architecture of an entire computer system. As an example, the Virtual PC software created by Connectix Corporation of San Mateo, Calif. emulates an entire computer that includes an Intel 80X86 Pentium processor and various motherboard components and cards. The operation of these components is emulated in the virtual machine that is being run on the host machine. An emulator program executing on the operating system software and hardware architecture of the host computer, such as a computer system having a PowerPC processor, mimics the operation of the entire guest computer system.
The emulator program acts as the interchange between the hardware architecture of the host machine and the instructions transmitted by the software running within the emulated environment. This emulated environment might be created by a virtual machine monitor (VMM) which is a software layer that runs directly above the hardware and which virtualizes all the resources of the machine by exposing interfaces that are the same as the hardware the VMM is virtualizing (which enables the VMM to go unnoticed by operating system layers running above it). In this configuration a host operating system (HOS) and a VMM may run side-by-side on the same physical hardware. Alternately, the emulator program may be the HOS itself running directly on the physical computer hardware and emulating another hardware configuration. In a specific implementation of this embodiment, the HOS software may specifically comprise one embodiment of a “hypervisor.”
A hypervisor is a control program that exists near the kernel level of a HOS and operates to allow one or more secondary operating systems, other than the HOS, to use the hardware of the computer system, including the physical processor(s) of the computer system. A hypervisor emulates the operating environment for the secondary operating system so that the secondary operating system believes that it is operating in its customary hardware and/or operating system environment and that it is in logical control of the computer system, even though it may in fact be operating in another hardware and/or operating system environment and that the HOS may be in logical control of the computer system. This is significant because many operating systems function such that the operating system must operate as though it is in exclusive logical control of the hardware of the computer system. Thus, for multiple operating systems to function simultaneously on a single computer system, the hypervisor of each operating system must function to mask the presence of the other operating systems such that each operating system functions as though it has exclusive control over the entire computer system.
For simplicity, processor virtualization programs, including but not limited to VMMs and hypervisors, are collectively referred to herein as “virtualizers.” Moreover, any aspect of the inventions disclosed herein in the context of a hypervisor are also presumed to be equally valid and disclosed for a VMM (or other virtualizers) and vice versa.
Interrupt Controllers
As known and appreciated by those of skill in the art, in typical computer systems (e.g., physical hardware executing a single operating system) the hardware devices (network cards, printers, other peripheral devices, etc.) communicate with the processor core software running on each processor core through interrupts. However, while there are several kinds of interaction between each processor core and the other hardware in the system, all such interactions initiated from outside the core are funneled through a single, simple interrupt delivery mechanism. Moreover, in traditional systems the number of interrupt vectors is very limited, which makes it necessary to group events together under a single common interrupt for each group. Thus when the processor core software receives an interrupt, it must take several steps to identify the cause and context of the interrupt since existing interrupt delivery mechanisms generally have no provisions for reliably identifying the source or cause of an interrupt. In addition, a single interrupt may also be indicative of only one of several similar events from a single physical or virtual device. For example, a messaging system implemented at a higher layer of abstraction may need hundreds or thousands of individually addressable signals in order to be performant, and the core processor software must determine which addressable signal corresponds with an interrupt received from these types of devices.
When the system is running under a hypervisor, VMM, or other machine virtualization technology (collectively “virtualizers”), the services presented by virtual devices to a partition (an instance of a virtual machine) will generally signal that partition via the same interrupt mechanism as hardware devices in a typical computer system. However, in a virtual machine environment, not only are devices for the virtual machine virtualized but so is the processor core(s) for each virtual machine. Consequently, the core processor software for each such virtualized processor core is further complicated by the fact that it must communicate with the virtualizer (e.g., the hypervisor or VMM) to actually handle interrupts where these interrupts may be generated by both hardware devices and virtualized devices (where the latter of which only exist as software). Because existing interrupt delivery mechanisms generally have no provisions for reliably identifying the source of an interrupt, especially ones generated by software, in a virtualized environment the processor resources required to identify the source and nature of an interrupt are substantially more costly. Moreover, data associated with an interrupt generally has to be widely accessible to hardware and system software, and trustworthy delivery is difficult under typical circumstances where a virtualizer is hosting multiple bodies of mutually distrustful system software. (Under such circumstances, there is a need to push information into partitions with interrupts, and any information associated with those interrupts needs to be protected from a malicious operating system in a neighboring partition, even when all partitions are participating in the same interrupt management scheme.)
Consequently, since interrupts may come from several different sources in each VM (including both hardware and software sources), many of which are “further away” than devices on a hardware bus (and thus require many more physical processor cycles to complete), what is needed in the art is a richer interrupt delivery mechanism that includes more information in order to enhance the performance and utility of a machine virtualization system.